Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR auto-syncs account schemas from VASP adapter field definitions in sparkcore, adding 8 new currency support (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) with their corresponding Key concerns:
Confidence Score: 3/5Not safe to merge without confirming the three breaking schema changes do not affect live production traffic. Three P1 findings involve breaking changes to existing schemas (EurBeneficiary requiring address, PhpAccountInfo tightening account number constraints, and mass removal of registrationNumber), plus two previously-flagged unresolved issues (LIGHTNING_ACCOUNT duplicate and ExternalAccountType.yaml not updated). The additive new-currency schemas themselves look correct. openapi/components/schemas/common/EurBeneficiary.yaml, openapi/components/schemas/common/PhpAccountInfo.yaml, openapi/components/schemas/common/AedBeneficiary.yaml (representative of all 24+ beneficiary files losing registrationNumber), and openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Added 8 new currency account types to the oneOf and discriminator mapping; the LIGHTNING_ACCOUNT duplicate mapping (flagged previously) is still present at line 88. |
| openapi/components/schemas/common/EurBeneficiary.yaml | Breaking change: address added to required, and optional registrationNumber property removed — existing EUR beneficiary clients not sending address will now fail validation. |
| openapi/components/schemas/common/PhpAccountInfo.yaml | Breaking constraint tightening: accountNumber changed from [1-34, any chars] to [8-16, numeric-only digits] — existing PHP accounts outside this range will fail validation. |
| openapi/components/schemas/common/PaymentInstructions.yaml | Added 8 new Payment*AccountInfo refs to the oneOf and discriminator mapping; consistent with new currencies added in external_accounts. |
| openapi/components/schemas/common/BdtAccountInfo.yaml | New file: BDT account schema with BANK_TRANSFER/MOBILE_MONEY rails, account number, branchCode, and phone; looks well-formed. |
| openapi/components/schemas/common/UsdAccountInfo.yaml | Additive change: BANK_TRANSFER added to the paymentRails enum — non-breaking. |
| openapi/components/schemas/common/UsdBeneficiary.yaml | birthDate and nationality removed from required (loosening — non-breaking); registrationNumber optional property removed (part of cross-currency cleanup). |
| openapi/components/schemas/external_accounts/BdtExternalAccountInfo.yaml | New file: BDT external account combining BaseExternalAccountInfo + BdtAccountInfo, with INDIVIDUAL/BUSINESS beneficiary discriminator. |
| openapi/components/schemas/common/AedBeneficiary.yaml | Representative of 24+ beneficiary schemas that had the optional registrationNumber property removed in this PR. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[ExternalAccountInfoOneOf.yaml] -->|oneOf| B[BaseExternalAccountInfo]
A -->|8 new entries| C[BDT / COP / EGP / GHS / GTQ / HTG / JMD / PKR ExternalAccountInfo]
C -->|allOf| B
C -->|allOf| D[Currency *AccountInfo\ne.g. BdtAccountInfo]
C -->|beneficiary oneOf| E[Individual Beneficiary\n e.g. BdtBeneficiary]
C -->|beneficiary oneOf| F[BusinessBeneficiary]
G[PaymentInstructions.yaml] -->|oneOf 8 new| H[Payment*AccountInfo\ne.g. PaymentBdtAccountInfo]
H -->|allOf| I[BasePaymentAccountInfo]
H -->|allOf| D
J[EurBeneficiary.yaml] -. "address now required" .-> K((Breaking Change))
L[PhpAccountInfo.yaml] -. "accountNumber 8-16 digits only" .-> K
M[24+ *Beneficiary.yaml] -. "registrationNumber removed" .-> K
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/EurBeneficiary.yaml
Line: 5
Comment:
**Breaking change: `address` added to required**
`address` has been added to the `required` array for `EurBeneficiary`. Before this PR, only `beneficiaryType` and `fullName` were required. Any existing client creating EUR beneficiaries without an `address` field will now fail schema validation.
This is a non-backwards-compatible tightening of an existing schema. If active production traffic submits EUR payments without `address`, those requests will be rejected after this change. Please confirm this is intentional and that downstream clients have been updated (or will be updated) before this is deployed.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/AedBeneficiary.yaml
Line: 23-25
Comment:
**`registrationNumber` removed from 24+ beneficiary schemas**
The `registrationNumber` property has been removed from the following beneficiary schemas in this PR: `AedBeneficiary`, `BrlBeneficiary`, `BwpBeneficiary`, `DkkBeneficiary`, `EurBeneficiary`, `GbpBeneficiary`, `HkdBeneficiary`, `IdrBeneficiary`, `InrBeneficiary`, `KesBeneficiary`, `MwkBeneficiary`, `MxnBeneficiary`, `MyrBeneficiary`, `NgnBeneficiary`, `PhpBeneficiary`, `RwfBeneficiary`, `SgdBeneficiary`, `ThbBeneficiary`, `TzsBeneficiary`, `UgxBeneficiary`, `UsdBeneficiary`, `VndBeneficiary`, `XafBeneficiary`, `XofBeneficiary`, `ZarBeneficiary`, `ZmwBeneficiary`.
While `registrationNumber` was optional (not required), removing it from the schema means clients that were previously sending it will be submitting a field that is no longer defined in the spec. Depending on whether the API enforces `additionalProperties: false`, this could cause validation failures. Please confirm this removal is intentional for all 24+ currencies and that no active integrations rely on this field.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/PhpAccountInfo.yaml
Line: 25-28
Comment:
**Breaking constraint tightening on `accountNumber`**
`accountNumber` for PHP (Philippine Peso) accounts previously accepted any string of 1–34 characters. This PR changes it to 8–16 digits only (via `pattern: ^[0-9]{8,16}$`). Any existing PHP external account whose `accountNumber` is fewer than 8 characters, more than 16 characters, or contains non-numeric characters will now fail validation.
Please verify that all existing PHP external accounts in production conform to `[0-9]{8,16}` before deploying this change.
How can I resolve this? If you propose a fix, please make it concise.Reviews (2): Last reviewed commit: "chore: Sync account schemas" | Re-trigger Greptile
d0e2fc3 to
2af53a0
Compare
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript
|

Auto-synced account schemas.
These schemas are generated from VASP adapter field definitions in sparkcore.
Synced schemas:
common/— per-currency account info, beneficiary, and payment account schemascommon/PaymentInstructions.yaml— payment instructions oneOf (new currencies added)external_accounts/— per-currency external account schemas (reference common/)Please review the changes before merging.